Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Konnektor

    

     

      
Version
      
5.18.0
     
     

      
Revision
      
571788
     
     

      
Stand
      
28.11.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_Kon
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Konnektor.

Dieses Dokument beschreibt die dezentrale Komponente zur sicheren Anbindung von Clientsystemen der Institutionen und Organisationen des Gesundheitswesens an die Telematikinfrastruktur – den Konnektor. Der Konnektor ist einerseits verantwortlich für den Zugriff auf die in der Einsatzumgebung befindlichen Kartenterminals sowie Karten und andererseits für die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten. Aus den Kommunikationsbeziehungen mit Clientsystem, Kartenterminals, Karten und zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten resultieren vom Konnektor anzubietende Schnittstellen, die gemeinsam in diesem Dokument sowie den fachanwendungsspezifischen Fachmodulspezifikationen normativ geregelt werden. Vom Konnektor genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (zentrale TI-Plattform aber auch Schnittstellen der Kartenterminals und Karten). Diese werden in den übergreifenden Spezifikationen der TI sowie den Produkttypspezifikationen definiert.

Dieses Dokument regelt somit nur einen Teil des Konnektors (wenngleich auch den Wesentlichen). Für die Implementierung eines Konnektors ist entsprechend die Kenntnis aller weiteren Spezifikationen erforderlich. Die Gesamtheit aller für den Konnektor relevanten Dokumente wird im Produkttypsteckbrief des Konnektors erhoben.

1.2 Zielgruppe

Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen (dies beinhaltet auch die Anbieter zur G2-Ausschreibung), die hierzu eine Schnittstelle besitzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Wichtiger Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Konnektor verzeichnet.

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

<AFO-ID> - *

Das Zeichen '*' steht hierbei für den Suffix der Anforderung. Es gilt der im Dokumentenpaket gültige Suffix.

1.5.2 Offene Punkte

Zum Zeitpunkt der Spezifikationserstellung konnten nicht alle Details abschließend geklärt werden, insbesondere, da Abstimmungsbedarf mit der umsetzenden Industrie besteht. Details, die keine produkttypübergreifenden Auswirkungen haben und die im Rahmen des Verhandlungsverfahrens mit der Industrie besprochen werden müssen, werden als „Offene Punkte“ ausgewiesen und wie folgt im Dokument kenntlich gemacht:

1.5.3 Erläuterungen zur Spezifikation des Außenverhaltens

Der Konnektor stellt einen vergleichsweise komplexen Produkttyp dar, dessen Beschreibung eine Herausforderung darstellt und somit in vielen verschiedenen Varianten möglich wäre. An dieser Stelle folgen daher wesentliche Informationen, die das korrekte Verstehen der Spezifikation fördern:

Die Spezifikation des Konnektors ist eine Black-Box-Spezifikation, das heißt alle Festlegungen dienen ausschließlich der Beschreibung des von der Komponente verlangten Verhaltens an der Außenschnittstelle.

Normative Festlegungen, die eine Festlegung des inneren Verhalten vermuten lassen (beispielsweise die Definitionen der Technischen Use Cases - TUCs) sind nur in so weit normativ, wie ihre Festlegungen auf die Außenschnittstelle wirken. Sie legen explizit nicht die intern zu verwendende Implementierung fest. Die Notwendigkeit für diese Art der „scheinbaren internen Beschreibung“ ergibt sich aus der Komplexität der Gesamtkomponente, sowie dem Bedarf, wiederholt ähnlich Verhaltensweisen in Außenschnittstellen darstellen zu müssen. In diesem Fall werden die sich wiederholenden Verhaltensanteile in internen TUCs zur editoriellen Wiederverwendung gekapselt. Die konkrete konnektorinterne Modularisierung bleibt dem Hersteller freigestellt. Insbesondere bleibt es dem Hersteller freigestellt, intern bereits Mechanismen für kommende Releases zu realisieren, sofern diese an der Außenschnittstelle keine Auswirkung zeigen.

Die einzige Abweichung von dieser Vorgehensweise ergibt sich für Sicherheitsaspekte. Hier können interne Vorgänge normativ gefordert sein, die sich an der Außenschnittstelle nicht manifestieren (Beispiel „Verpflichtung auf sicheres Löschen eines temporären Schlüssels nach Gebrauch“). In diesem Fall erfolgt die Überprüfung der Einhaltung dieser Anforderungen im Rahmen der CC-Evaluierung.

1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“

1.5.4.1 Modulare Spezifikation über Funktionsmerkmale

Die Beschreibung des Konnektors erfolgt soweit wie möglich modular, d. h. alle Aspekte, die für einen logischen Bereich relevant sind, werden in einem Kapitel beschrieben. Diese logischen Bereiche werden als Funktionsmerkmal bezeichnet.

Funktionsmerkmale kennzeichnet ein eigener Verantwortungsbereich. In diesen Verantwortungsbereich greifen keine anderen Funktionsmerkmale ein. So kann ein logischer Bereich vollständig durchdrungen werden, ohne dass in anderen Kapiteln Anforderungen zu erwarten wären, die das Verhalten des Funktionsmerkmals beeinflussen. Da zwischen Funktionsmerkmalen Wechselwirkungen bestehen (Die Erkennung einer gesteckten Karte im Kartenterminaldienst löst eine Reaktion im Kartendienst aus), wurden zur „dokumententechnischen Interaktion“ zwischen Funktionsmerkmalen ein interner Event-Mechanismus sowie Konfigurationsparameter und Zustandswerte eingeführt (siehe Folgekapitel).

Funktionsmerkmale bestehen (bis auf wenige Ausnahmen) immer aus folgenden Unterkapiteln:

1. Funktionsmerkmalweite Aspekte
2. Durch Ereignisse ausgelöste Reaktionen
3. Interne TUCs, nicht durch Fachmodule nutzbar
4. Interne TUCs, auch durch Fachmodule nutzbar
5. Operationen an der Außenschnittstelle
6. Betriebsaspekte

Die Unterkapitel 1-5 dienen der funktionalen Beschreibung des Funktionsmerkmals.

Punkte, die zum Funktionieren des Funktionsmerkmals relevant sind: Initialisierungsaspekte, durch den Administrator festzulegenden Konfigurationsparameter etc., werden im Unterkapitel Betriebsaspekte erfasst.

In jedem Funktionsmerkmal sind immer alle Unterkapitel enthalten, auch wenn es im konkreten Einzelfall dort keine Inhalte gibt. Diese feste Struktur innerhalb der Funktionsmerkmale erleichtert die Orientierung und erhöht somit die Lesbarkeit.

1.5.4.2 Technische Use Cases - TUCs

Innerhalb der Funktionsmerkmale in Kapitel 4 erfolgt eine Unterscheidung der TUCs in solche, die nur durch die Basisdienste des Konnektors aufgerufen werden dürfen (rein interne TUCs) und solche die neben den Basisdiensten auch durch Fachmodule genutzt werden dürfen. Diese Unterteilung ergibt sich ausschließlich aus dem Bedarf der editoriellen Steuerung der verschiedenen Spezifikationen (Konnektor- und Fachmodulspezifikationen). Es besteht im Rahmen der Implementierung des Konnektors keine Anforderung diese Trennung intern durchzusetzen.

Die Beschreibung der TUCs erfolgt nach folgendem Muster:

• TUC-Tabelle
• Aktivitäts- oder Sequenzdiagramm (optional)
• Fehlercodetabelle

Dabei wird innerhalb der TUC-Tabelle in der Zeile „Standardablauf“ ausschließlich der Gut-Durchlauf beschrieben. Fehler, die innerhalb dieses Ablaufs auftreten können, werden in der Zeile „Fehlerfälle“ erhoben. Dabei wird auf die jeweilige Schrittnummer innerhalb des Ablaufs referenziert. In dieser Tabellenzeile werden nur Fehlercodes erhoben, die im jeweiligen Fehlerfall geworfen werden müssen. Die genauen Festlegungen zu den Fehlern, neben Fehlercode auch: ErrorType, Severity und Fehlertext, werden in der Fehlercodetabelle festgelegt.    

Die Spezifikation, in der ein TUC definiert wird, ist an den mittleren drei Buchstaben der TUC-Referenz zu erkennen:

• TUC_KON_xxx entsprechend in dieser Konnektorspezifikation
• TUC_PKI_xxx in der PKI-Spezifikation [gemSpec_PKI]
• TUC_VPN_ZD-xxxx in der Spezifikation des VPN-Zugangsdienstes [gemSpec_VPN_ZugD]
• TUC_VZD_xxx in der Spezifikation des Verzeichnisdienstes [gemSpec_VZD]

Festlegungen zur Schreibweise von Eingangs- und Ausgangsdaten von TUCs

a) Eingangs- und Ausgangsparameter werden in TUC-Tabellen wie folgt beschrieben:

Name des Eingangs- bzw. Ausgangsparameters

gefolgt von (falls definiert):[Datentyp]

gefolgt von (falls zutreffend):

- optional; default: <Defaultwert> bzw.

- optional;/<erklärender Text>  

Hierbei bedeuten:

- optional; kennzeichnet optionale Ein- und Ausgangsparameter

default: <Defaultwert> definiert den Defaultwert für den Fall, dass der Eingangsparameter leer ist bzw. nicht übergeben wurde

/ <erklärender Text> beschreibt Bedingungen, unter denen der Eingangsparameter optional ist

     gefolgt von (falls vorhanden):(<erklärender Text>)

b) Namen mit kleinem Anfangsbuchstaben bezeichnen Ein- und Ausgangsparameter; Namen mit großem Anfangsbuchstaben bezeichnen Datentypen.

Beispiel:

Die im Dokument verwendeten Datentypen sind definiert in [Anhang L – Datentypen von Eingangs- und Ausgangsdaten].

Festlegungen zur Schreibweise des Aufrufs von TUCs

Ein TUC-Aufruf erfolgt nach folgendem Muster:

<TUC-Bezeichner> {

   <TUC-Eingangsparameter Name> = <TUC Eingangsparameter Wert>;

   … }

Beispiel:

TUC_KON_256 {
    topic = „CT/DISCONNECTED“;
    eventType = Op;
    severity = Info;
    parameters = („CtID=$CT.CTID, Hostname=$CT.HOSTNAME“) }

Vereinfachung:

Ist <TUC-Eingangsparameter Name> des aufzurufenden TUCs gleich der Variablen, die als < TUC Eingangsparameter Wert> gesetzt wird, so kann dieser Bezeichner ohne Zuweisung geschrieben werden.

Beispiel: (cardSession und pinRef sind Eingangsdaten des aufrufenden TUCs):

TUC_KON_022 „Liefere PIN-Status“ {cardSession=cardSession; pinRef=pinRef}

vereinfachte Schreibweise:

TUC_KON_022 „Liefere PIN-Status“ {cardSession; pinRef}

1.5.4.3 Event-Mechanismus

Der in Kapitel 4.1.6 spezifizierte Event-Mechanismus zur Unterrichtung von Clientsystemen wird innerhalb dieser Spezifikation auch zur internen Verzahnung der einzelnen Funktionsmerkmale eingesetzt. So wird ein Ereignis, das in der Managementschnittstelle durch Änderung eines Konfigurationsparameters ausgelöst wird, innerhalb des DHCP-Kapitels als Trigger für eine Lease-Erneuerung verwendet. Dies bedeutet nicht, dass im Rahmen der Implementierung intern ein Event-Mechanismus zwischen den Modulen verwendet werden muss. Auch hier dient die Form der Darstellung (Events) lediglich der editoriellen Kopplung verschiedener Verhaltensbeschreibungen.

Um den Ursprung eines Events erkennen zu können, verwenden alle Events ein Haupt-Topic passend zum Funktionsmerkmal: „DHCP/LAN_CLIENT/RENEW” wird im Funktionsmerkmal DHCP ausgelöst, „CARD/INSERTED” wird im Funktionsmerkmal Kartendienst ausgelöst usw.     

1.5.4.4 Konfigurationsparameter und Zustandswerte

Werte die der Administrator des Konnektors einsehen oder verändern können muss, werden zusätzlich zu den Festlegungen in Kapitel 4.3 Konnektormanagement auch pro Funktionsmerkmal in den jeweiligen Unterkapiteln „Betriebsaspekte“ erhoben. Diese Konfigurationsparameter werden über eine ReferenzID definiert. Definierte Konfigurationsparameter können in allen Kapiteln der Spezifikation referenziert werden. Den Ort, an welchem ein solcher Konfigurationsparameter definiert/erhoben und somit dessen Bedeutung beschrieben wird, lässt sich über den Präfix der ReferenzID erkennen: CERT_CRL_DOWNLOAD_ADDRESS (also „Cert“) wird im Zertifikatsdienst definiert, MGM_LU_ONLINE (also „MGM“) wird im Konnektormanagement definiert usw.

Die ReferenzIDs der Konfigurationsparameter besitzen in ihrer Schreibweise nur innerhalb des Dokuments Gültigkeit. In der Umsetzung können für die Konfigurationswerte herstellerspezifische Beschreibungen und Labels verwendet werden.

Vergleichbar zu diesen Konfigurationsparametern, sind Zustandswerte. Auch diese werden über ReferenzIDs definiert, nur können sie nicht durch den Administrator verändert oder eingesehen werden. Sie finden nur konnektorintern Verwendung und sind für die Beschreibung der Verhaltensweise notwendig, Beispiele sind CTM_CT_LIST für die Liste der durch den Konnektor verwalteten Kartenterminals oder CM_CARD_LIST für die Liste der aktuell erreichbaren Karten. Zustandswerte verwenden die gleichen Präfixe wie Konfigurationsparameter.

2 Systemüberblick

Der Konnektor ist ein Produkttyp der TI gemäß [gemKPT_Arch_TIP#5.3.9].

Er bietet seine Basisdienste sowohl intern den in ihm laufenden Fachmodulen an, als auch externen Clientsystemen über die Konnektoraußenschnittstellen.

Im lokalen Netz der Einsatzumgebung kommuniziert das Clientsystem mit dem Konnektor über dessen LAN-seitiges Ethernet-Interface. Alleinig der Konnektor kommuniziert mit den in lokalen Netzen angeschlossenen Kartenterminals und Karten. Auch die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten erfolgt ausschließlich über den Konnektor über dessen WAN-seitiges Ethernet-Interface.

Abbildung PIC_KON_116 stellt die Schnittstellen im Umfeld des Konnektors dar.

Abbildung 1: PIC_KON_116 Schnittstellen des Konnektors von und zu anderen Produkttypen

Die logischen Außenschnittstellen aus [gemKPT_Arch_TIP] werden im Konnektor technisch vorrangig als SOAP-Schnittstellen ausgeprägt. Von dieser Regel wird insbesondere bei Netzwerkschnittstellen abgewichen, wenn bereits etablierte Schnittstellenstandards für Basisdienste existieren (IPsec, TLS, NTP, DNS etc.). Eine Übersicht der Zuordnung „logische Schnittstellen  technische Schnittstellen“ findet sich in Anhang H.

Zum Nachweis der Sicherheit müssen Konnektoren im Rahmen der Zulassung nach Common Criteria gegen die Schutzprofile [PP_NK] und [PP_KON] evaluiert und zertifiziert werden.

Die zu verwendenden kryptographischen Verfahren und zugehörige Parameter (z. B. Schlüssellängen) für alle kryptographischen Operationen innerhalb der Telematikinfrastruktur, werden durch das Dokument „Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur“ [gemSpec_Krypt] normativ geregelt.

2.1 Logische Struktur

Der Produkttyp Konnektor besitzt eine Vielzahl verschiedenster Operationen und Verhaltensweisen an seiner Außenschnittstelle. Um sein komplexes Gesamtverhalten sinnvoll beschreiben zu können, wird der Konnektor innerhalb dieser Spezifikation logisch unterteilt und strukturiert. Es wird primär zwischen Anwendungs- und Netzkonnektor unterschieden, begleitet von Mechanismen, die blockübergreifend beschrieben werden.

Der logische Aufbau des Konnektors ist in Abbildung PIC_KON_117 dargestellt.

• Der Anwendungskonnektor bietet anwendungsnahe Basisdienste (inklusive Signaturdienst) und Fachmodule zur Nutzung durch ein Clientsystem an. 
• Der Netzkonnektor bietet transportnahe Basisdienste und verbindet das lokale Netz der Nutzer mit der zentralen TI-Plattform.
• Die gSMC-K ist zwar ein eigenständiger Produkttyp innerhalb der TI, wird im Konnektor jedoch als Verbaukomponente betrachtet. Sie enthält die kryptographischen Identitäten des Konnektors, sowie Steuerdaten (Umgebungsinformationen TU/RU/PU, zugehörige Adressbereiche, herstellerspezifische Konfigurationsdaten), die aus Sicherheitsgründen unveränderlich in den Konnektor eingebracht werden müssen.
• Das Konnektormanagement dient der administrativen Verwaltung und Steuerung des gesamten Konnektors.
• Der Sichere Datenspeicher dient der integeren, vertraulichen und authentischen Persistierung von veränderlichen Daten (siehe auch Kapitel 2.2).

Abbildung 2: PIC_KON_117 Logische Zerlegung des Konnektors in Anwendungs- und Netzkonnektor

Diese logische Unterteilung schreibt in keiner Art und Weise die spätere Implementierung durch den Hersteller vor. Der Hersteller kann seine interne Modularisierung des Konnektors frei wählen. Normativ wirksam ist ausschließlich das durch die Detailfestlegungen in Summe beschriebene Verhalten an den Außenschnittstellen des Konnektors als Ganzes.

2.2 Sicherer Datenspeicher

Wie im vorherigen Kapitel dargestellt, wird für den Konnektor ein Datenspeicher angenommen, in welchem der Konnektor alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert, die für seinen Betrieb relevant sind. Dieser Datenspeicher sichert die Integrität, Authentizität und Vertraulichkeit der in ihm hinterlegten Daten bzw. der aus ihm entnommenen Daten. Alleinig der Konnektor hat auf diesen Datenspeicher Zugriff. Für folgende, im weiteren Verlauf der Spezifikation anfallende Daten wird angenommen, dass diese im Sicheren Datenspeicher persistiert werden:

• Der Trust Store des Zertifikatsdienstes
• Die Konfigurationsdaten des Konnektormanagements
• Die Konfigurationsdaten aller Funktionsmerkmale

Ferner stellt der Konnektor den in ihm laufenden Fachmodulen ebenfalls eine Nutzung dieses Datenspeichers für ihre sensiblen Daten zur Verfügung.

Da es sich bei dem Sicheren Datenspeicher um ein internes Modul handelt, welches an der Außenschnittstelle nicht testbar ist, werden an dieses Modul im Rahmen dieser Spezifikation keine Anforderungen erhoben. Da dieses logische Modul aber essenzielle Sicherheitsfunktionen bietet, ohne die ein Konnektor nicht sicher betrieben werden kann, werden die Funktionen, die ein Hersteller für sein Konnektormodell real umsetzt, um die notwendigen sicheren Speicherfunktionen zu realisieren, im Rahmen der CC-Evaluierung geprüft werden. Näheres hierzu regeln die Schutzprofile des Konnektors.

2.3 Überblick Konnektoridentität

Die Geräteidentität des Konnektors (Konnektoridentität) teilt sich in drei Identitäten auf:

• ID.NK.VPN für den Netzkonnektor    
  Die Identität des Netzkonnektors dient der Authentisierung gegenüber den zentralen Netzwerkdiensten und wird für die Anmeldung an den VPN-Konzentrator genutzt.
• ID.AK.AUT für den Anwendungskonnektor    
  Die Identität des Anwendungskonnektors dient der Authentisierung gegenüber den Clientsystemen im Rahmen von TLS-Verbindungen.
• ID.SAK.AUT für die im Anwendungskonnektor enthaltene Signaturanwendungskomponente
  Die Identität des Signaturdienstes dient zur Authentisierung gegenüber den Kartenterminals. Darüber hinaus muss sich der Signaturdienst des Konnektors gegenüber dem Heilberufsausweis mittels eines kartenverifizierbaren Zertifikats (C.SAK.AUTD_CVC) mit entsprechendem Profil ausweisen, um Stapelsignaturen durchführen zu können.  

In der Regel ergibt sich aus dem Kontext, welche Identität gemeint ist, sodass in diesen Fällen nur kurz von der Konnektoridentität geschrieben wird.

Die Geräteidentitäten werden durch asymmetrische Schlüssel und X.509-Zertifikate umgesetzt. In Abhängigkeit vom gewählten kryptographischen Verfahren werden RSA-Schlüssel bzw. ECC-Schlüssel verwendet.

2.4 Mandantenfähigkeit

Den Anforderungen aus [gemKPT_Arch_TIP#TIP1-A_2200] folgend, wird die Mandantenfähigkeit innerhalb des Konnektors nicht durch eine einzelne Funktion, sondern durch Berücksichtigung in einer Reihe von Funktionsmerkmalen umgesetzt.

Die Mandantenfähigkeit wirkt dabei auf:

• Zugriffsberechtigungsdienst: Kapitel 4.1.1    
  (und über diesen auf alle Karten- und Kartenterminaloperationen)
• Systeminformationsdienst: Kapitel 4.1.6

2.5 Versionierung

Gemäß [gemSpec_OM] müssen Konnektor und Kartenterminals über eine Versionierung verfügen. Die relevanten Versionsinformationen sind durch das O&M-Schema ProductInformation.xsd definiert. Ferner definiert [gemSpec_OM], dass Konnektor und Kartenterminal das Konzept der Firmware-Gruppe verwenden müssen. Daher verfügen die beiden Produkttypen auch über eine aktuelle Firmware-Gruppenversion.

Versionsinformationen werden innerhalb des Konnektor an folgenden Stellen ver- und bearbeitet:

• Dienstverzeichnisdienst (Kapitel 4.1.3): Ausgabe der Konnektorversion über SOAP
• Kartenterminaldienst (Kapitel 4.1.4): Anzeige der Versionsinformationen der verwalteten Kartenterminals
• Konnektormanagement (Kapitel 4.3):
• Anzeige der Versionsinformationen des Konnektors (Kapitel 4.3.2)
• Software-Aktualisierung (KSR-Client) für Konnektor und Kartenterminals (Kapitel 4.3.9)

2.6 Fachanwendungen

Der Konnektor ist als Plattformkomponente der TI für die Erbringung von Basisdiensten verantwortlich. Fachliche Funktionalitäten werden über die Fachmodule bereitgestellt.

Das Fachmodul wird dabei als integraler Bestandteil des Konnektors verstanden (Konnektor als Monolith), d. h., die Spezifikationen zu Konnektor (als Plattformkomponente) und dem Fachmodul sind zwar getrennt, werden aber von einem Hersteller in einer Gesamtkomponente umgesetzt. Die inneren Schnittstellen zwischen Fachmodul und Konnektor sind von außen nicht erkennbar.

In dieser Ausbaustufe unterstützt der Konnektor die Fachanwendungen VSDM, AMTS, NFDM und ePA über jeweils ein Fachmodul.

Neben Fachanwendungen, die über ihr Fachmodul mit einem gesicherten Fachdienst kommunizieren, unterstützt der Konnektor einen Zugriff von Clientsystemen auf offene Fachdienste.

2.7 Netzseitige Einsatzszenarien

Der Konnektor unterstützt unterschiedliche netzseitige Einsatzszenarien, die in Anhang K beispielhaft dargestellt sind.

Der Konnektor bietet hierzu Konfigurations-Parameter, die je nach netzseitigem Einsatzszenario konfiguriert werden müssen.

2.7.1 Parameter ANLW_ANBINDUNGS_MODUS

Konfiguration 1: Konnektor als Gateway (ANLW_ANBINDUNGS_MODUS = InReihe):
Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor zwischen das lokale Netz und das Internet Access Gateway (IAG) (z. B. Router mit DSL-/Kabelmodem) geschaltet wird. (vgl. Anhang K, Szenario 1)

Konfiguration 2: Konnektor eingebettet in existierende Infrastruktur (ANLW_ANBINDUNGS_MODUS = Parallel): Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor als weiteres Gerät in die bestehende Netzwerkinfrastruktur integriert wird. (vgl. Anhang K, Szenario 3)

Aus Sicherheitsgründen soll die Kommunikation der Clientsysteme mit dem Konnektor hierbei verschlüsselt erfolgen (ANCL_TLS_MANDATORY=Enabled). Falls diese Kommunikation unverschlüsselt erfolgt (ANCL_TLS_MANDATORY=Disabled), übernimmt der Nutzer die Verantwortung für die Sicherstellung der vertraulichen Übertragung.

Für den Einsatz und die Nutzung von DHCP gibt es im Zusammenhang mit diesem Konfigurationsparameter folgende Möglichkeiten:

• Die Netzwerkinfrastruktur der Einsatzumgebung verwendet den DHCP-Server des Konnektors (siehe Kap. 4.2.2).
• Ein bestehender DHCP-Server im Netz der Einsatzumgebung wird weiter verwendet und derart konfiguriert, dass als Default Gateway und DNS-Server entweder bestehende Infrastruktur oder der Konnektor verwendet wird.
• Es kommt kein DHCP-Server zum Einsatz. Bei allen Clients im Netz der Einsatzumgebung werden das Default Gateway und der DNS-Server statisch auf den Konnektor gesetzt.

Die DHCP-Konfiguration ist in Konfiguration 1 in aller Regel die folgende: Die WAN-Seite des Konnektors verwendet den DHCP-Server des bestehenden IAG. An der LAN-Seite stellt der Konnektor einen DHCP-Server für alle Clients zur Verfügung.

2.7.2 Parameter ANLW_INTERNET_MODUS

Grundsätzlich routet der Konnektor im Modus ANLW_INTERNET_MODUS=SIS alle für das Internet bestimmten Pakete von Clients, die ihn als Default Gateway verwenden, in den VPN-Tunnel zum SIS, während er im Modus ANLW_INTERNET_MODUS=Keiner diese Pakete verwirft.

Im Unterschied zu (ANLW_ANBINDUNGS_MODUS = InReihe) ist die Nutzung des SIS bei (ANLW_ANBINDUNGS_MODUS = Parallel) optional. Alternativ können auch die Clients, die den Konnektor als Default Gateway verwenden, per Redirect direkt ins Internet verwiesen werden (ANLW_INTERNET_MODUS=IAG).

2.8 Lokale und entfernte Kartenterminals

Gemäß [gemKPT_Arch_TIP] ermöglicht die Telematikinfrastruktur dem Anwender die PIN-Eingabe zur Freischaltung eines HBAs oder einer SMC-B wahlweise lokal oder über das Remote-PIN-Eingabeverfahren durchzuführen. Deshalb unterscheidet auch der Konnektor zwischen einem lokalen Kartenterminal – räumlich („in Sichtweite“) dem Arbeitsplatz zugeordnet – und einem entfernten Kartenterminal.

Ein lokales Kartenterminal befindet sich lokal an einem Arbeitsplatz und kann von diesem aus genutzt werden. Hingegen ist das entfernte Kartenterminal einem entfernten oder auch – für zentral steckende Karten – keinem Arbeitsplatz fest zugewiesen. Ein lokales Kartenterminal kann als sogenanntes Remote-PIN-KT verwendet werden, um die PIN für eine in einem entfernten Kartenterminal steckende Karte einzugeben.

2.9 Standalone-Szenario

Gemäß § 291 Absatz 2b SGB V müssen „Diese Dienste [zur Online-Aktualisierung der Versichertendaten auf der eGK] […] auch ohne Netzanbindung an die Praxisverwaltungssysteme der Leistungserbringer online genutzt werden können.“

Dies bedeutet, dass der Konnektor ohne ein steuerndes Clientsystem ereignisgetrieben Fachanwendungen ausführen können muss. Aus Fachsicht „steht der Konnektor alleine“, ohne Clientsysteme. Die konkreten Aktionen, die Fachanwendungen in diesen Fällen ausführen, sowie deren Auslöser werden in den jeweiligen Fachmodulspezifikationen beschrieben.

Ein solcher alleinstehender Konnektor mit Zugang zur TI muss zur Durchführung der Fachanwendungen durch einen weiteren Konnektor unterstützt werden, der in direkter Verbindung zum Clientsystem steht, selbst aber keine Online-Anbindung besitzt.

3 Übergreifende Festlegungen

Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens" sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

In diesem Kapitel werden die Aspekte des Konnektors behandelt, die Funktionsmerkmalübergreifend geregelt werden müssen.

Die Managementschnittelle/Administrationsoberfläche des Konnektors wird dabei nicht als übergreifender Aspekt, sondern als eigenes Funktionsmerkmal gewertet. Die Festlegungen hierzu finden sich entsprechend in Kapitel 4.3.

3.1 Allgemeine übergreifende Festlegungen

3.1.1 Dokumentformate

Mit dem Aufruf einer Operation, die Dokumente verarbeitet, muss durch den Aufrufer festgelegt werden können, um welches Dokumentenformat es sich handelt, damit die unterschiedlichen Formate zur Verarbeitung und etwaigen Anzeige unterschieden werden können. Die nicht-XML-Formate werden dabei nach MIME-Typ-Klassen unterschieden:

• „PDF/A” für MIME-Typ „application/pdf-a” gemäß [ISO 19005],
• „Text” für MIME-Typ „text/plain”,
• „TIFF“ für MIME-Typ „image/tiff” gemäß [TIFF6]
• „Binär“ für alle übrigen MIME-Typen.

Folgende Bezeichner werden verwendet:

Alle_DocFormate:      XML, PDF/A, Text, TIFF, Binär

nonQES_DocFormate:    XML, PDF/A, Text, TIFF, Binär

QES_DocFormate:        XML, PDF/A, Text, TIFF

Für nonQES_DocFormate wird, trotz Gleichheit zu Alle_DocFormate, ein eigener Referenzbezeichner verwendet, da sich diese Liste noch ändern könnte. TIFF wird durch [gemKPT_Arch_TIP] nicht für die nonQES verlangt. Die Unterstützung dieses Formats für nonQES bedeutet jedoch keinen Mehraufwand, da die Routinen durch QES bereits implementiert sind und nachgenutzt werden können.

3.1.2 Kartentypen

Der Konnektor unterstützt eine Reihe von Kartentypen. Die folgende Tabelle enthält die Liste der Referenzbezeichner für die verschiedenen Kartentypen, wie sie im weiteren Verlauf verwendet werden. Die Unterstützung von Karten der Generation 2 (G2.x: G2.0, G2.1 und höher) beschränkt sich bei diesen auf die Datenstrukturen und Schlüssel, die aus Gründen der Abwärtskompatibilität zu den Karten der Generation 1+ vorhanden sind. Eine Ausnahme hiervon bilden die Geräte-CVCs, die bereits für dieses Release basierend auf ECC verwendet werden.

Tabelle 3: TAB_KON_500 Wertetabelle Kartentypen

3.1.3 Übergreifende Festlegungen zum Aufbau von sicheren Verbindungen

In [gemSpec_Krypt#6] wird das Kommunikationsprotokoll zwischen einem Client und einer Vertrauenswürdigen Ausführungsumgebung (VAU) spezifiziert. Dabei wird ein sicherer Kanal auf HTTP-Anwendungsschicht zwischen dem Client und der VAU (Server) aufgebaut. Der Client ist hier ein Fachmodul des Konnektors; der Server ist ein Fachdienst.

Der Gesamtablauf der Schlüsselableitungsfunktionalität gemäß [gemSpec_SGD#2.3] für den Konnektor als Client ist aufgeteilt zwischen Basiskonnektor und Fachmodul. Die kryptographischen Vorgaben (u.a. Durchführung des ECDH, Schlüsselerzeugung, Ver- und Entschlüsselung, Signaturerzeugung und -prüfung) werden dabei durch den Basiskonnektor realisiert.

3.2 Konnektoridentität und gSMC-K

Die Notwendigkeit, den Konnektor mit mehr als einer gSMC-K zu bestücken, kann sich aus den Lastanforderungen aus [gemSpec_Perf#4.1.2] ergeben.

gSMC-Ks gemäß [gemSpec_gSMC-K_ObjSys] verfügen über die Möglichkeit zur nachträglichen Generierung von Schlüsselpaaren und dem Nachladen der zugehörigen Zertifikate. Dieser Mechanismus wird erst in kommenden Releases durch den Konnektor unterstützt. Initial sind alle Identitäten bereits einmal auf der gSMC-K vorhanden.

3.2.1 Organisatorische Anforderungen und Sperrprozesse

Die Anforderung ist für die Anwendungsfälle Registrierung, IPsec-Authentisierung und Autorisierung beim VPN-Zugangsdienst, TLS-Authentisierung zum eHealth-Kartenterminal, TLS-Authentisierung zum Primärsystem nachzuweisen. Wenn RSA-2048 in der TI abgekündigt wird, entfällt dadurch die Anforderung.

Das bedeutet, dass der Konnektorhersteller je Konnektor die für die Identifikation des C.NK.VPN-Zertifikates relevanten Daten wie z. B. Seriennummer des Konnektors und Art der verbauten Komponenten, Seriennummer der gSMC-K, etc. für seinen Sperrprozesse dokumentieren muss.

Sperrberechtigt ist die gematik im Rahmen des Change-Verfahrens (siehe [gemRL_Betr_TI#5.4).

Dazu bedient er die standardmäßige Schnittstelle zum TSP (siehe [gemSpec_X.509_TSP#TIP1-A_3643]).

Der Hersteller des Konnektors übernimmt im Rahmen der organisatorischen Sperrung die Aufgabe der Anwenderkommunikation gegenüber den betroffenen Anwendern. Die Eckpunkte zur Kommunikation sind Bestandteil des Beschlusses zur Außerbetriebnahme einer Konnektor-Baureihe und im Rahmen des Change-Verfahrens zwischen den Beteiligten abgestimmt.

Dies kann bspw. durch Übertragung der Aufgabe an einen Dritten realisiert werden. Dabei sind die Zuordnungen Konnektor zu Zertifikat gemäß Anforderung „Dokumentation der Konnektorzertifikatszuordnungen“ zur Verfügung zu stellen.

Bei der Schlüsselerzeugung für die gSMC-K muss insbesondere auch mit technischen Maßnahmen die Vertraulichkeit der relevanten Schlüssel sichergestellt werden:

3.3 Bootup-Phase

Die hier gelisteten TUCs bilden nicht die abschließende Menge der während der Bootup-Phase zu erfüllenden Anforderungen. In den einzelnen Funktionsmerkmalen werden weitere Einzelanforderungen erhoben, die als Ausführungszeitpunkt die Bootup-Phase benennen (siehe Unterkapitel „Betriebsaspekte“ der einzelnen Funktionsmerkmal-Kapiteln, sowie Kapitel 4.3 Konnektormanagement).

3.4 Betriebszustand

Erklärung „Minütlich gleitende 10-Minuten-Summe“: Für die jeweilige Operation wird die Summe aller OK_Val und NOK_Val der letzten 10 Minuten gebildet. Diese Summe wird jede Minute neu berechnet.

Unter „kartenbasiert“ sind nicht nur Lösungen mit Smartcards sondern auch solche mit HSMs (Hardware Security Modules) zu verstehen.

Tabelle 6: TAB_KON_504 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen

In den kritischen Fehlerzuständen, in denen keine TLS-Verbindung ins LAN aufgebaut werden (EC_Random_Generator_Not_Reliable, EC_Software_Integrity_Check_Failed, EC_Security_Log_Not_Writable, EC_Time_Sync_Pending_Critical, EC_Time_Difference_Intolerable, EC_NK_Certificate_Expired), kann keine Verbindung zu den Kartenterminals aufgebaut werden. Infolge sind hier keine Kartenoperationen zugelassen.

Wenn keine Verbindung zum VPN-Konzentrator des SIS aufgebaut werden kann, ist dadurch das Internet nicht über den Konnektor erreichbar. Wenn keine Verbindung zum VPN-Konzentrator der TI aufgebaut werden kann, sind Bestandsnetze nicht erreichbar.

Bezüglich der Administration des Konnektors im Zustand EC_FIREWALL_NOT_RELIABLE ist eine Abstimmung mit der Prüfstelle und der Zertifizierungsstelle notwendig.

Die Architektur der TI ist so angelegt, dass die Fehlerzustände mit Severity=Fatal in den Tabellen TAB_KON_504 und TAB_KON_503 mit vernachlässigbarer Wahrscheinlichkeit von externen Einflüssen abhängen. Die SLAs für Dienste der zentralen TI-Plattform sind so gefasst, dass diese schwerwiegend verletzt werden müssten, um dadurch einen Konnektor in einen solchen kritischen Zustand zu bringen (externer Fehler aus Sicht des Konnektors). Dass beispielsweise der TSL-Dienst über den Zeitraum der Grace-Period-TSL (typisch: 7 Tage) nicht erreichbar ist (ErrorCondition EC_TSL_Out_Of_Date _Beyond_Grace_Period), kann nur bei massiver Verletzung der für zentrale Dienste festgelegten SLAs eintreten.

Um die konnektorinternen Fehlerquellen zu erfassen, die dazu führen, dass ein Fehlerzustand mit Severity=Fatal eintritt oder ein anderer Zustand, in dem der Konnektor nicht verwendbar ist, wird Folgendes gefordert:

Bei einem mittleren Zeitabstand zwischen Ausfällen (MTBF) von 50 Jahren ist die Wahrscheinlichkeit, dass ein Fehlerzustand mit Severity=Fatal auftritt, kleiner 2 % pro Jahr.

3.4.1 Betriebsaspekte

Der Konnektor soll per Signaleinrichtung am Konnektor die Fehlerzustände mit Severity „Error“ und „Fatal“ anzeigen (siehe [TIP1-A_4843]).

3.5 Fachliche Anbindung der Clientsysteme

Für die Schnittstellen des Konnektors zu den Clientsystemen kann gesteuert werden:

• ob die Kommunikation zwischen Konnektor und Clientsystemen hinsichtlich Vertraulichkeit, Integrität und Authentizität zwingend durch TLS gesichert werden muss
• ob sich Clientsysteme zwingend authentisieren müssen
• welche Clientsysteme auf den Konnektor zugreifen dürfen

Dabei werden die folgenden zwei Nutzungsszenarien nicht unterschieden:

• Nutzung von Fachanwendungen (in Form von Fachmodulen)
• Nutzung von Basisdiensten des Konnektors

Sowohl die Anbindung zur Administration des Konnektors, als auch die Anbindung zur Nutzung von Bestandsnetzen oder dem gesicherten Internetzugang sind nicht Gegenstand dieser Schnittstellenfestlegungen. Für die Anbindung zu Administration wird diese im Kapitel Konnektormanagement beschrieben, für die Anbindung von Bestandsnetzen bzw. dem gesicherten Internetzugang ist diese Art der Regelung nicht erforderlich, da es sich dort um Routing-Funktionen handelt.

Die seitens des Administrators einstellbaren Werte und Listen sind, der allgemeinen Struktur dieses Dokuments folgend, im Unterkapitel 3.4.1 Betriebsaspekte beschrieben.

Bei der Authentisierung des Clientsystems geht es um eine Authentisierung in zwei Richtungen:

1. Authentisierung des Clientsystems in der Rolle eines Clients gegenüber dem Konnektor für die Übertragung von SOAP-Requests.
2. Authentisierung des Clientsystems in der Rolle eines Servers gegenüber dem Konnektor zum Empfang von CETP-Ereignismitteillungen des Systeminformationsdienstes.

Für beide Richtungen kann das Clientsystem dasselbe Zertifikat verwenden.

Für die Anbindung der Clientsysteme ergeben sich verschiedene Konfigurationsvarianten bezüglich der Absicherung der Verbindungen zwischen Konnektor und Clientsystemen. Tabelle TAB_KON_852 listet die Varianten für die Verbindungen zum Aufruf der WebService-Schnittstellen (Varianten SOAP1 bis SOAP4), für die Verbindungen zum Senden von Events (Varianten CETP1 und CETP2) und für Verbindungen zum Abruf des Dienstverzeichnisses (Varianten DVD1, DVD2 und DVD3).

Tabelle 9: TAB_KON_852 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen

Client-Authentisierung bei Nutzung des LDAP-Proxy

Für die Nutzung des LDAP-Proxy gelten abweichende Festlegungen, da viele Standard LDAP- / Mail-Clients grundsätzlich keine Funktion zur Client-Authentisierung anbieten. Um die Nutzung des LDAP-Proxy und somit des VZD der TI dennoch zu ermöglichen, ohne dabei auf eine verpflichtende Client-Authentisierung für SOAP-Aufrufe zu verzichten, werden für LDAP gesonderte Regelungen getroffen.

Aus A_21224 resultiert direkt, dass als Client-Authentisierung für LDAPS nur Client-Zertifikate unterstützt werden müssen. Die Authentisierung mit Username/Passwort wird bei LDAPS nicht unterstützt.

Es sei noch einmal betont, dass TIP1-A_5009 sich nur auf SOAP und CETP bezieht und TIP1-A_4516 das Basic-Authentication Verfahren nur für HTTP fordert.

3.5.1 Betriebsaspekte

Damit sich ein Clientsystem mittels X.509 authentisieren kann, muss es über ein entsprechendes Zertifikat verfügen. Diese Zertifikate kann der Administrator entweder mit seinen lokalen Mitteln selbst oder mittels des Konnektors erzeugen. In beiden Fällen müssen diese Zertifikate sowohl im Clientsystemen (hier zusammen mit ihren privaten Schlüsseln), als auch im Konnektor vorhanden sein.

Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zu den Schlüsselspeichern auf Clientsystemseite erhoben. Auch hinsichtlich der außerhalb des Konnektors erzeugten Zertifikate gelten keine weiteren Vorgaben. Ferner ist eine Online-Prüfung dieser Zertifikate nicht erforderlich.

Damit sich der Konnektor mittels X.509 gegenüber Clientsystemen authentisieren kann, muss er über ein entsprechendes Zertifikat und dazu passendes Schlüsselmaterial verfügen. Dieses Zertifikat und Schlüsselmaterial befinden sich auf der gSMC-K (ID.AK.AUT). Der Administrator hat neben der Konfiguration zur Nutzung des erneuerten C.AK.AUT , welches vom Konnektor heruntergeladen wurde, auch mehrere Möglichkeiten, die ID.AK.AUT von der gSMC-K für die Authentisierung gegenüber den Clientsystemen zu ersetzen:

• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial Konnektor-extern mit seinen lokalen Mitteln erzeugen und in den Konnektor importieren oder
• er kann ein Zertifikat und das dazugehörige Schlüsselmaterial im Konnektor erzeugen und das Zertifikat ggf. aus dem Konnektor exportieren.

Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zur Erstellung und Handhabung in der LE-Umgebung der außerhalb des Konnektors erzeugten Zertifikate und Schlüssel erhoben. Eine Online-Status-Prüfung dieser Zertifikate ist nicht erforderlich und nicht vorgesehen.

3.6 Clientsystemschnittstelle

3.6.1 SOAP-Schnittstelle

Für die Beschreibung der SOAP-Schnittstelle zum Clientsystem wird in dieser Spezifikation WSDL Version 1.1 [WSDL1.1] eingesetzt. Die Interoperabilität zwischen verschiedenen SOAP-Implementierungen wird durch die Vorgaben des WS-I Basic Profile erreicht.

Da der Konnektor UTF-16 nicht unterstützt, muss das Clientsystem den Request in UTF-8 kodieren. Diese Festlegungen gelten nur für die eigentliche SOAP-Nachricht. Sind in der SOAP-Nachricht base64-encodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichencodierungen aufweisen.

Fachmodule

Fachmodule können für Web-Services, die Clientsystemen bereitgestellt werden, entweder [SOAP1.1] mit [BasicProfile1.2] oder [SOAP1.2] mit [BasicProfile2.0] verwenden. Die genaue Ausprägung erfolgt in der jeweiligen Interfacebeschreibung des Web-Services für das Fachmodul.

3.6.2 Statusrückmeldung und Fehlerbehandlung

Der Konnektor bietet Operationen an der Außenschnittstelle über SOAP-Webservices an. Treten bei der Ausführung einer Operation Fehler auf, so werden diese an das aufrufende System gemeldet. Die von den Basisdiensten des Konnektors angebotenen SOAP-Webservices melden Fehler, die bei der Ausführung einer Operation auftreten, über eine SOAP-Fault-Nachricht (siehe auch [gemSpec_OM#3.2.3]).

Treten bei konnektorinternen Operationen (TUCs) Fehler auf, so werden diese an den Aufrufer (aufrufender TUC oder aufrufende Operation) zurückgegeben. Der Aufrufer kann den aufgetretenen Fehler in seinem Kontext neu interpretieren. Das bedeutet insbesondere, dass ein Error eines aufgerufenen TUCs nicht zwingend zum Abbruch des aufrufenden TUCs bzw. der aufrufenden Operation führen muss. So ist es dem Aufrufer möglich, einen Error als Warnung zu interpretieren und an den eigenen internen oder externen Aufrufer zurückzumelden. Diese dabei erzeugte Fehlerkette wird in Form einer Fehler-Trace-Struktur abgebildet, um eine Nachverfolgung von Fehlern zu ermöglichen.

Operationen an der Außenschnittstelle können die Fehlerkette zu Informationszwecken in der SOAP-Antwort an das Clientsystem senden. Dazu enthält jede SOAP-Antwort das Element Status, dass gemäß dem XML-Schema [ConnectorCommon.xsd] aufgebaut ist (siehe auch Abbildung PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort).

Abbildung 3: PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort

Schlägt eine Operation fehl, so wird eine SOAP-Fault-Meldung an das Clientsystem versendet. Im Erfolgsfall wird das Status-Element in die Antwortnachricht an das Clientsystem aufgenommen. Ist der Fehler-Trace leer (Element GERROR:Error ist nicht vorhanden), so wird CONN:Result auf OK gesetzt. Andernfalls, d. h. wenn in GERROR:Trace Fehler der Schwere Info oder Warning (zu Informationszwecken) enthalten sind, wird CONN:Result auf Warning gesetzt.

In der Regel ist es ausreichend, wenn die GERROR-Struktur an der Außenschnittstelle nur ein Element „GERROR:Trace“ mit einem gematik-Fehler enthält.

Wenn für eine Fehlersituation kein Fehlercode spezifiziert ist, kann ein herstellerspezifischer Fehler zur Detaillierung verwendet werden. In diesem Fall muss ein passender gematik-Fehler als letztes GERROR:Trace-Element gewählt werden.  Bei Fehlern in technischen Abläufen kann Fehlercode 4001 als letztes GERROR:Trace-Element verwendet werden. Die Wahl des letzten GERROR:Trace-Elements ist mit der gematik abzustimmen.

Zur Struktur von Fehlermeldungen siehe auch [gemSpec_OM#GS-A_3856-*].

3.6.3 Transport großer Dokumente

SOAP Message Transmission Optimization Mechanism (MTOM) ermöglicht den direkten Transport von binären Daten in Webservices, d.h. ohne dass eine zur Laufzeit aufwändige Verpackung der binären Daten in ein Base64-XML-Element notwendig wird. Auf die Definition der Webservices und ihre Funktionalität hat dieser Optimierungsmechanismus keinen Einfluss. Der Einsatz von MTOM dient der Verbesserung des Performance-Verhaltens für große Dokumente.

Das Clientsystem kann die Optimierung des Transports großer Dokumente per SOAP Message Transmission Optimization Mechanism (MTOM) anstoßen. In den WSDL-Dateien werden keine MTOM Serialization Policy Assertion [WS-MTOMPolicy] eingebettet.

3.7 Verwendung manuell importierter CA-Zertifikate

TI-fremde X.509-Zertifikate werden im Rahmen des Verschlüsselungsdienstes verwendet. Um den Vertrauensraum für diese Zertifikate abzubilden, erlaubt der Konnektor, X.509-CA-Zertifikate zu diesen TI-fremden X.509-Zertifikaten in eine interne Liste (CERT_IMPORTED_CA_LIST) zu importieren.

Der Konnektor kann dann im Rahmen der Hybridverschlüsselung den symmetrischen Schlüssel empfängerspezifisch mit dessem TI-fremden X.509-Zertifikat verschlüsseln. Die TI-fremden Zertifikate dürfen nicht zu einem anderen Zweck als diesem eingesetzt werden.

Die Berücksichtigung der CA-Zertifikate aus CERT_IMPORTED_CA_LIST muss auf folgende Anwendungsfälle beschränkt werden:

1. Prüfung eines Zertifikates im Rahmen der hybriden Verschlüsselung

2. Prüfung eines Zertifikates im Rahmen eines Aufrufes der Operation "VerifyCertificate"

3.8 Testunterstützung

Gemäß Testkonzept der TI [gemKPT_Test#TIP1-A_6526] muss ein Hersteller eines Konnektors seine Modelle in verschiedenen Ausführungen vorsehen: für Testumgebung, für die Referenzumgebung und für die Produktivumgebung.
Damit trotz dieser Forderung die Firmware je Konnektorversion für alle Umgebungen identisch ist, wird die Erkennung der Umgebung an die gSMC-K gebunden. Die Konnektor-Firmware muss zwischen den Umgebungen PU und RU/TU unterscheiden. Die gSMC-K besitzt hierzu den Datencontainer MF/EF.EnvironmentSettings, der die jeweilige Umgebungskennung enthält (PU bzw. TU/RU). Die Umgebungskennung wird read-only auf der gSMC-K gespeichert.

4 Funktionsmerkmale

Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens„ sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

4.1 Anwendungskonnektor

4.1.1 Zugriffsberechtigungsdienst

Der Zugriffsberechtigungsdienst ist ein interner Dienst. Er ermöglicht es Operationen eine Prüfung auf Zugriffsberechtigung für die von ihnen benötigten Ressourcen durchzuführen. Die Prüfung erfolgt direkt nach Aufruf einer Operation des Konnektors durch das Clientsystem und basiert auf den im Clientaufruf enthaltenen Parametern.

Der Zugriffsberechtigungsdienst definiert über ein Informationsmodell die erlaubten Zugriffsmöglichkeiten. Um dies zu erreichen, modelliert es Mandanten und ordnet ihnen Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (Kartenterminal mit Slots, Arbeitsplatz mit SMC-Bs) zu. Diese durch einen Administrator persistent zu modellierenden Entitäten und Beziehungen beinhalten die erlaubten Zugriffswege vom Clientsystem über Arbeitsplatz zum Kartenterminal und dessen Slots. Sie werden im Konnektor administrativ konfiguriert.

Neben diesen persistenten Entitäten und Beziehungen bildet das Modell auch die in den Slots temporär gesteckten Karten und die zugehörigen Kartensitzungen als transiente Entitäten und Beziehungen ab.

Abbildung PIC_Kon_100 stellt das Informationsmodell dar. Die persistenten Entitäten haben einen grünen Hintergrund, die transienten einen weißen.

Tabelle TAB_KON_507 beschreibt die Entitäten und legt ihren Identitätsschlüssel fest. Tabelle TAB_KON_508 beschreibt die Attribute. Tabelle TAB_KON_509 beschreibt die Entitätsbeziehungen und referenziert dabei die in Abbildung PIC_Kon_100 durch Zahlen in eckigen Klammern markierten Beziehungen. Tabelle TAB_KON_510 definiert Constraints, die zusätzlich zu den in Abbildung PIC_Kon_100 definierten Kardinalitäten gelten. Die Constraints werden mittels Object Constraint Language (OCL) definiert.

4.1.1.1 Funktionsmerkmalweite Aspekte

Hinweis zu den Bezeichnern der Entitäten und ihrer Attribute: Im Folgenden beginnen Entitäten mit einem Großbuchstaben, Attribute mit einem Kleinbuchstaben. Werden die Entitäten und Attribute in XML-Dokumenten verwendet, so beginnen die zugeordneten XML-Elementbezeichner grundsätzlich mit einem Großbuchstaben und verwenden den englischen Begriff, der im Folgenden in Klammern angegeben ist, wenn zur besseren Lesbarkeit im Modell ein deutscher Begriff verwendet wird.

Abbildung 4: PIC_Kon_100 Informationsmodell des Konnektors

Tabelle 13: TAB_KON_507 Informationsmodell Entitäten

Tabelle 14: TAB_KON_508 Informationsmodell Attribute

Tabelle 15: TAB_KON_509 Informationsmodell Entitätenbeziehungen

Tabelle 16: TAB_KON_510 Informationsmodell Constraints

Hinweis zur Remote-PIN-Eingabe: Constraints C14 und C15 legen fest, dass auch im Fall mehrerer lokaler Kartenterminals an einem Arbeitsplatz nur eines (oder keines) dieser Kartenterminals pro Mandant für die Remote-PIN-Eingabe im Informationsmodell konfiguriert wird.

4.1.1.2 Durch Ereignisse ausgelöste Reaktionen

Keine.

4.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

Keine.

4.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar

4.1.1.4.1 TUC_KON_000 „Prüfe Zugriffsberechtigung“

Vor Ausführung jeder Operation an der Außenschnittstelle muss der Konnektor prüfen, ob die Operation ausgeführt werden darf (Autorisierung). Diese Prüfung auf Zugriffsberechtigung wird in TUC_KON_000 „Prüfe Zugriffsberechtigung“ gekapselt.

TUC_KON_000 „Prüfe Zugriffsberechtigung“ hat als Aufrufparameter den Aufrufkontext der Operation (siehe Abbildung PIC_KON_101), optional das cardHandle einer Karte, optional eine Kartenterminal-ID ctId und optional die Steuerungsparameter „needCardSession“ sowie „allWorkplaces“. Über den Steuerungsparameter „needCardSession“ wird festgelegt, ob zu den CardHandles im Rahmen der Operationsausführung eine Kartensitzung benötigt wird. Über den Steuerungsparameter „allWorkplaces“. wird festgelegt, ob die Auswertung im Rahmen der Operation arbeitsplatzübergreifend für alle vom Mandanten für das angegebene Clientsystem erreichbaren Kartenterminals erfolgen soll.

Abbildung 5: PIC_KON_101 Aufrufkontext der Operation

Eine Beschreibung aller Zugriffsregeln gibt Tabelle TAB_KON_512.

Tabelle 18: TAB_KON_512 Zugriffsregeln Beschreibung

Abbildung 6: PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“

Welche Zugriffsregel für einen gegebenen Satz an Aufrufparametern anzuwenden ist, wird in Tabelle TAB_KON_513 ermittelt. Die Pflichtfelder mandantId, clientSystemId und workplaceId und das optionale Feld userId sind zwar für die Auswertung der Regeln wichtig, tragen aber nicht zur Auswahl der Regel bei und sind daher in der Tabelle nicht vorhanden. Zur Auswahl einer Regel ist relevant,

• ob ctId bzw. cardHandle als Aufrufparameter gesetzt sind (not null) oder leer sind (null),
• von welchem Typ eine Karte ist, falls der Aufrufparameter cardHandle gesetzt ist,
• und welchen Wert die Aufrufparameter „needCardSession“ und „allWorkplaces“ annehmen.

Tabelle 19: TAB_KON_513 Zugriffsregeln Regelzuordnung

Tabelle TAB_KON_514 definiert einzelne Bedingungen, ordnet sie den Regeln zu und definiert ErrorCodes für den Fall, dass eine Bedingung nicht erfüllt ist.

Die Bedingungen in Tabelle TAB_KON_514 sind wie folgt gruppiert:

• Entitäten: Hier wird geprüft, ob die Entitäten, die mit den Aufrufparametern adressiert werden, im Informationsmodell existieren.
• Mandantenbezug: Hier wird geprüft, ob die adressierten Entitäten im Informationsmodell dem adressierten Mandanten zugeordnet sind.
• Relationen: Hier wird geprüft, ob die benötigen Zugriffbeziehungen zum Zugriff auf die adressierten Entitäten im Informationsmodell existieren.
• Kartensitzungen: Hier wird geprüft, ob die benötigte Kartensitzung im Rahmen der bereits existierenden Kartenbeziehungen existieren darf.

Die Fehlercodes mit Beschreibung, ErrorType und Severity Tabelle TAB_KON_515.

Tabelle 20: TAB_KON_514-01 Zugriffsregeln Definition